As technology advances, computers provide increasingly useful and rapid service to their users. Much of the advantage provided by computers, however, arises as a derivative of the increased processing speed, that is, the ability to run larger and more complex programs. Of course, many tasks performed by a computer, such as clearing a display of graphics, connecting to a network, etc., are repetitive. Thus, one method of simplifying the job of programming is to re-use software routines as much as possible. As software continues to evolve, then, and programs become more complex, increasingly reliance is placed on the re-use and recycling of various modules that support application program operations. Software modules or subroutines that are routinely used by other programs are often grouped into a single program file, known as a “library.”
Using the Microsoft Windows™ operating system (hereinafter “Windows™”) as a well-known example, it is understood by those skilled in the art that a popular library file type can be recognized in a file listing by the appended designation characters “DLL.” Those who formulate these dynamic link library files, or “DLL files” often intend that they be used by many different programs. Similar to other popular types of software programs, DLL files are subject to constant improvement and upgrades. Moreover, as is often the case with other types of software programs, upgrades for DLL files are typically published under a new version number, have an updated creation date, may include a version check sum, etc.
To further elaborate, an application program might make use of a DLL file having the name “DRIVE.DLL.” This library may be published, upon initial release, with a version number of “1.0.” Minor upgrades or changes to version 1.0 may in turn be published with a version number of “1.05” or “1.1.” These minor upgrades or changes to the DLL file may include small revisions to the DLL file code to improve the functionality of the program, or possibly to correct minor flaws in operational functionality. Major changes to the DLL file will usually be accompanied by a greater numerical change in the version number. Therefore, by tracking the version number attached to any particular software code or library, it is possible to gain an idea as to whether the most recent version of the software is being used. More importantly, observing the version number attached to the software code will also give information as to whether the correct version of the code is being used.
Similarly, tracking other attributes of a DLL file may also indicate whether the correct version of the code is being used. For example, a creation date of a DLL file may be referenced in order to determine if the correct DLL file is being used. Furthermore, other attributes identifiable within DLL files may be used in order to determine whether a correct version of the DLL file is being used.
Most software application programs make use of auxiliary software codes, including libraries, such as the exemplary DLL files described above. One of the most common problems when using such software codes is loading an improper version of the code by the application software, which may occur in several different ways. For example, one application may load one version of a DLL file, while another instance of the same application loads a different version of the same DLL file. Alternatively, a single application may load a DLL file version that differs from a previously-loaded version. Either occurrence may cause the application to perform erroneously. Such erroneous behavior may hamper the usability of the application that loaded the DLL file.
Computer processors used today are firmware programmed to handle executable code that may cause an operating system and/or application to behave in an undesirable manner. For example, an application that attempts to load a DLL file that is not intended therefore, or that is a DLL file that is intended for an older version of the application, may cause a processor to unexpectedly halt a processing operation if an attempt is made to execute code out of data memory. If this occurs, an operating system running in conjunction with the processor may not continue to operate properly. Oftentimes, the operating system will need to be restarted in order to reestablish the proper interface between the operating system and the processor. To prevent this undesirable behavior by an operating system, processors are now robust and can handle out of date DLL files, erroneous DLL files, or otherwise misbehaving code before the actual operation of the operating system is affected.
In some cases, an operating system and/or invoking application will analyze an out of date or erroneous DLL file before it is actually executed. This occurs, for example, if an operating system and/or an invoking application determines the called DLL file has a different version number. If the processor finds that the DLL file is not that which is expected by the operating system and/or invoking application, loading or execution of the DLL file is simply abandoned. Although this does not render the interface of the operating system inoperative, the result is nonetheless undesirable to the user. In particular, often the result is the incorrect operation of the application that attempted to launch the DLL file.
Since the occurrence of application programs attempting to use (or re-use) commonly available auxiliary software codes is increasing, such as, for example, the DLL files provided for use with Windows™, there remains a need to determine and identify DLL files that are operational with current operating systems and processors, but yet are otherwise considered out of date.